fix(ci): install a Rust toolchain in the bump-version jobs - #653

What's broken

Every push to main since 2026-07-26 has produced a red CI run — four in a row (ed704e6a #646, 7937a53b #649, f903e8e0 #650, 48c46423 #652) — while all seven build/test jobs stayed green. The only failing job each time is Bump Version:

error: rustc 1.92.0 is not supported by the following packages:
  sqlx@0.9.0 requires rustc 1.94.0
  ...
  wfl@26.7.53 requires rustc 1.94
Error: locked fuzz check failed after bump; refusing to stage a broken fuzz/Cargo.lock

Side effect: the bump never landed, so main is stuck at version 26.7.52 and no v* tags were pushed for those four commits.

Root cause

bump-version runs python scripts/bump_version.py --update-all, which shells out to Cargo three times — cargo update --package wfl for the root lock, the same for fuzz/Cargo.lock, and finally cargo check --locked --manifest-path fuzz/Cargo.toml as a guard so a bump can never stage a fuzz lock that the fuzz-check gate would then reject.

The job never installed a toolchain. Every other Cargo-running job in this repo uses dtolnay/rust-toolchain@stable; this one silently inherited whatever rustc the runner image preinstalled. That worked on GitHub-hosted images and stopped working the moment CI moved to Blacksmith runners (#646), whose ubuntu-2404 image ships rustc 1.92.0 — below our rust-version = "1.94" (raised by the sqlx 0.9 dependency).

It was easy to miss because the Cargo dependency is invisible in the workflow file — it hides behind a Python script, so scanning ci.yml for cargo finds nothing in this job. #646 only changed the job's runs-on: label.

The fix

• .github/workflows/ci.yml — add dtolnay/rust-toolchain@stable before the bump step, plus a restore-only Swatinem/rust-cache sharing fuzz-check's fuzz-check-cache key so the locked fuzz check reuses that job's build instead of recompiling the workspace on every push to main.
• .github/workflows/versioning.yml — the manual-dispatch bump-version job has the identical latent defect and would fail the same way the next time anyone triggered it. Same one-line fix.

Deliberately not changed: the cargo check --locked guard inside bump_version.py. It did exactly its job — it caught a broken environment and refused to commit a lockfile it could not verify. Relaxing it would trade a loud failure for a silently stale fuzz/Cargo.lock.

Test evidence

• Risk class: R1 — build/release tooling; no runtime or language behavior changes, no public contract touched.

• Acceptance criteria → tests (all in tests/workflow_rust_toolchain_test.rs):

  Acceptance criterion	Test
  Every job that runs Cargo — directly or via a scripts/*.py indirection — installs a toolchain before the first Cargo use	cargo_jobs_install_a_rust_toolchain_first
  The Cargo-invoking script inventory cannot silently go stale	cargo_invoking_scripts_list_is_complete
  Comment-only cargo mentions are ignored; real jobs are still found	scanner_ignores_comments_and_finds_jobs
  Only genuine setup counts — echo rust-toolchain and rustup target/component add do not	toolchain_markers_reject_incidental_mentions
  Cargo-argv detection survives whitespace/quote/multi-line reformatting	script_cargo_detection_tolerates_whitespace_and_argv_forms
  A toolchain installed after the first Cargo step is out of order, not satisfying	toolchain_after_cargo_is_out_of_order

• Red evidence: commit 2ab115d is test-only and an ancestor of the fix. It fails there for the intended reason — before any workflow edit existed:

  no toolchain step: ["ci.yml:bump-version", "versioning.yml:bump-version"]
  

  It caught the versioning.yml instance too, which nobody had reported. After the scanner was tightened in review, it was re-checked against the original defect: removing the toolchain step from ci.yml again fails the guard with no toolchain step: ["ci.yml:bump-version"], so the hardening did not cost it its bite.

• Unit/component: cargo test --test workflow_rust_toolchain_test → ok. 6 passed; 0 failed (rustc 1.94.1).

• Lint/format: cargo fmt --all -- --check clean; cargo clippy --all-targets --all-features -- -D warnings clean.

• Full workspace suite: CI run 30240210815 on this branch — Build, Test, Clippy green including its Run Tests step, plus integration, database, fuzz-compile and WFL-program jobs on Linux and Windows. A local cargo test --all was attempted but exhausted the authoring container's disk allowance mid-link (a Bus error from the ~30 GB target/ tree documented in CLAUDE.md) — an environment limit, not a test failure; CI runners carry the Free disk space step the container lacks.

• End-to-end / real boundary: cargo check --locked --manifest-path fuzz/Cargo.toml — the exact command that failed in CI — run locally on rustc 1.94.1: exit 0, Finished dev profile in 2m 04s.

• Coverage: the guard covers all 8 workflow files and every job in them; it flagged 2 of the 11 Cargo-using jobs and passes on all 11 after the fix.

• Platforms: the fixed jobs run on blacksmith-4vcpu-ubuntu-2404; the guard itself is platform-independent (static file analysis).

• Not applicable, with reason: no §11.3 concurrency/streaming/lifecycle tests — this change adds a CI setup step and touches no runtime code, async path, or untrusted input. No docs-example validation — no user-facing syntax, stdlib, CLI flag, or config option changed.

• Rollback/recovery: revert this PR; CI returns to its current (red Bump Version) state, no external state to unwind. After merge the bump job resumes from 26.7.52 and pushes the next version + tag normally.

• Residual risk: the guard is a line scanner, not a YAML parse (the repo carries no YAML dependency), so it assumes job ids are the only two-space-indented keys under jobs: — true for all current workflows and asserted by a scanner self-test. It cannot see Cargo invoked from a shell script or a composite action; only scripts/*.py indirection is resolved.

Note on verification limits: bump-version is gated on github.event_name == 'push' && github.ref == 'refs/heads/main', so it cannot run on this PR (it shows as skipped). This PR's CI proves nothing regressed; the definitive proof of the fix is the Bump Version job on the post-merge push to main.

Dev Diary: Dev diary/2026-07-27-ci-bump-version-toolchain.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Sfkzn8nZgGEddsoYWAf3BC